A “terrain database” is a set of data which allows a simulation or a visualization to understand, at a computational geometry level, the ground, roads, buildings, vegetation and other static elements of a simulated world. Terrain databases are typically large, which means that they take time to load from external storage (e.g., hard disk, optical disk, network storage) into working memory, where the data can be used for simulation computation. The “working memory” of a computer, as the term is used herein, is the memory from which executable instructions are normally executed by the computer and/or where operands and other data and results of executing the instructions are normally stored for purposes of execution. Traditionally, working memory is implemented as random access memory (RAM), although that does not have to be the case.
Examples of terrain databases include game levels (such as an industrial complex, simulated city or enchanted forest) as well as real-world data (ranging from a single building, for example, up to the entire world and even space).
Applications that use terrain databases include simulation based applications, such as massively multiplayer online gaming and three-dimensional (3D) virtual worlds. These two types of applications commonly involve multiple human users using separate computer systems on a large-scale computer network, such as the Internet, to participate in a simulation. Normally at least one computer maintains the state of various simulation objects that can be displayed on a display device, such as a computer monitor. The objects may represent real-world objects, such as people, animals, vehicles, structures, etc., at least some of which may be controlled by human users. The state of an object can include the object's display position on a display device, its physical orientation, size, shape, color, as well as attributes that may not be visible or perceivable to a human user.
In traditional simulations and computer games, the entirety of a terrain database is loaded at once into the working memory of a computer executing the simulation or game. This lets any action within the world have immediate access to the data, but limits the overall size of the terrain database used for simulation. Examples of this approach can be seen as “levels” within a computer game. Two drawbacks of this approach are that each level takes a while to load (leaving the user waiting), and events that cover a large area cannot be simulated in real time.
In modern computer games, the terrain database may be so large that it cannot fit in its entirety into the working memory of a computer that executes the game. Consequently, a method known as “streaming” is sometimes applied, where the player (or virtual camera) can move around large areas, and in the context of simulation, at some limited velocity. The terrain database is broken into many smaller pieces. The pieces that overlap some neighboring area to the player or camera location are loaded into memory, whereas other pieces are unloaded. This loading and unloading at the boundary of the visible area typically runs asynchronously in the background, and with a known loading speed from the storage medium, a defined experience can be provided.
This “streaming” technique lets a single viewpoint move around the virtual world, at a limited velocity, letting the user partake of a large terrain database without any noticeable loading delays. However, as only a small area of the world, directly surrounding the user or camera location, is loaded at any one time, any simulated action in another part of the world must be paused during the times that those parts are not loaded. Yet pausing simulation of one or more objects may be unacceptable for certain applications, particularly multi-user, multi-object distributed simulations or games. Hence, with traditional methods of streaming, a server executing a simulation that includes multiple user-controlled simulated objects cannot stream out of a terrain database, because there is no single point of focus.
In modern massively multi-player games, the concept of streaming on the client is often combined with the concept of separating load geographically onto different server computers. Each server is designated a specific area of the virtual world and loads all the terrain data for that area. When a player comes within the zone served by that server, simulation authority for the player is moved onto that server, from whatever server previously was simulating the player (or his avatar). This approach allows a distributed server system to simulate a relatively large area with low latency (because each server preloads all of its terrain data), while letting the player have a seamless experience (due to client streaming). This approach is used in some of the most advanced simulation and gaming systems.
Note that the designers of many current distributed simulation systems, even massively multiplayer games, choose to avoid the complexity of distributed servers and streaming clients, and instead implement a one-to-one mapping between server area and client-side levels. In such systems, there are defined portals where the client will stop and load a new level (terrain database), and at the same time, simulation responsibility is handed over to a new server. Each server process then preloads its defined level, and nothing more. The system can therefore easily deliver a defined experience (measured in simulation capacity and latency) relating to terrain, since the amount of terrain data is static on both server and client. However, the area which can be simulated on any particular server is limited in size by the size of its working memory (e.g., RAM).